同样是写代码,你和大神究竟差在哪里?
The following article is from 异步图书 Author 异步图书
脚本之家
你与百万开发者在一起
很多程序员都有这么一个梦想——自己写的代码,可以像诗一样优美;自己做的设计,能恰到好处,既不过度,也无不足。
这种带有一点洁癖的完美主义就像一把达摩克利斯之剑,仿佛时刻在提醒着:不能将就、不能妥协。完美主义的代价是会在很长时间里持续的迷茫和焦虑。
每每看到这些像面条一样缠绕在一起代码,都会令人感到气愤、懊恼和羞愧。
怎么办?一边是无止尽的业务需求,一边是补丁加补丁的业务代码,开发人员被夹在中间像一只困兽,向左走,还是向右走?方向在哪里?不明白为什么花了那么多时间来学习技术,可还是写不好代码;为什么花了这么多时间加班,还是应对不了复杂度。
代码精进之路
就像Robert C. Martin说的:“不管你们有多敬业,加多少班,在面对烂系统时,你任然会寸步难行,因为你大部分的精力不是在开发需求,而是在应对混乱。”
其实,造成软件复杂性的罪魁祸首主要来自以下因素:
● 软件的本质复杂性——《人月神话》的作者Fred Brooks曾说:“软件的复杂性是一个基本特征,而不是偶然如此”。因为问题域有其复杂性,而软件在实现过程中又有很大的灵活性和抽象性,导致软件具有天然的复杂属性。
中间变量
我们可以通过添加中间变量让代码变得更加自明,即将计算过程打散成多个步骤,并用有意义的变量名来命名中间变量,从而把隐藏的计算过程以显性化的方式表达出来。
例如,我们要通过Regex来获得字符串中的值,并放到map中。
用中间变量,可以写成如下形式:
中间变量的这种简单用法,显性地表达了第一个匹配组是key,第二个匹配组是value。只要把计算过程打散成一系列良好命名的中间值,不透明的语义自然会变得透明。
领域驱动
领域驱动设计关心的是业务中的领域划分(战略设计)和领域建模(战术设计),其开发过程不再以数据模型为起点,而是以领域模型为出发点,研发过程如下图所示。领域模型对应的是业务实体,在程序中主要表现为类、聚合根和值对象,它更加关注业务语义的显性化表达,而不是数据的存储和数据之间的关系。这是“领域驱动设计”和“数据驱动设计”之间显著的区别。
仍以上面的CRM为例。假如我们先不考虑数据模型,而是采用面向对象分析(Object Oriented Analysis,OOA)对这个场景进行领域建模,那么可以得到下图所示的领域模型。
可以看到,领域模型的描述更加贴近业务,一些重要的业务术语和概念没有丢失,更完整地表达了业务语义。即使是产品经理或者业务人员,也不难看懂这样的领域模型,甚至他们可以和技术人员一起参与到梳理领域模型和创建活动中来。
通过DDD的战略设计和战术设计,我们可以为问题域划分出合适的子域,并对域中的业务进行建模。下图是我们在实际工作中为CRM进行的领域战略设计。
资深大牛,良心创作
这是一本为专业程序员而写的书,写好代码、追求卓越和工匠精神是每个程序员都应该具备的优秀品质。
本书简介,提纲挈领
👇下滑看目录:
● 第一章 命名
● 第二章 规范
● 第三章 函数
● 第四章 设计原则
● 第五章 设计模式
● 第六章 建模
● 第七章 DDD的精髓
● 第八章 抽象
● 第九章 分治
● 第十章 技术人的素养
● 第十一章 技术Leader的修养
● 第十二章 COLA架构
● 第十三章 工匠平台
发表您在学习编程过程中的经验感想,机会总是靠自己去争取来的!小编将对留言进行精选,被精选的留言才会在留言区显示并获得相应的楼层(由于微信留言功能限制,最多只能显示100条)。
踩楼送书活动获奖须知:
1、活动结束时踩中已放在百度云文件中指定楼层的精选留言将获得 《 代码精进之路 从码农到工匠》一本,共3名中奖者
(扫码了解本书详情)
2、活动结束后我们会在本公众号公布中奖楼层的解压密码,并在3个工作日内联系到获奖用户将奖品送出(收到奖品的小伙伴欢迎来留言区晒晒。)
3、获奖楼层下载地址(文件解压密码会在2019年12月31日推送的中奖文章中公布)
百度云链接:https://pan.baidu.com/s/1_rupOw3Ky2o3ZU0sGGuXng
提取码: 7m48
活动时间
活动时间:即日起至2019年12月31日下午4点整
精选书单 点蓝字即可
♡ 我放弃Python转Go语言的9大理由 | 优秀书籍推荐
更多好书请关注脚本之家官方书店